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FOREWORD 


This  report  documents  the  results  of  a  study  conducted 
for  the  purpose  of  developing  a  preliminary 
implementation  approach  for  an  Automated  Tactical 
Aircraft  Launch  and  Recovery  System  (ATALARS)  Proof-of- 
Concept  (POC)  model.  The  study  was  conditional  on  the 
premise  of  using  existing  or  planned  systems  in 
evolving  the  POC  model. 

The  approach  taken  was  based  on  the  ATALARS  system 
concept  as  presented  in  ESD-TR-86-259 .  This  basic 
ATALARS  system  concept  was  further  refined  under  an 
SBIR  study  report  performed  by  Airspace  Technology 
Corporation  under  Contract  F19628-87-C-0195 .  The  POC 
model  described  herein  follows  the  operational  and 
performance  characteristics  described  in  those  two 
documents . 

The  POC  model  will  address  two  major  elements  in  the 
baseline  ATALARS  concept/conf iguratiori :  the  Data  Link 
and  the  Processing  and  Display  functions.  The  plan  is 
to  implement  the  model  using  a  combination  of 
commercial  and  developmental  equipment.  Certain 
elements  and  features  will  be  based  on  the  Surveillance 
Restoral  Vehicle  (SRV)  which  is  presently  in  Full  Scale 
Development . 

This  study  effort  was  performed  under  the  guidance  of 
Lt.  Melissa  Greer,  ESD/XR.  The  Project  Leader  was  Mr. 
D.  B.  Whitney  with  Mr.  T.  M.  Katanik  as  the  primary 
contributor. 
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SECTION  1 
INTRODUCTION 


This  report  contains  the  results  of  a  USAF  contracted  study  for  a 
preliminary  implementation  approach  to  produce  a  proof  of  concept 
demonstration  of  the  Automated  Tactical  Aircraft  Launch  and 
Recovery  System  (ATALARS) .  This  study  effort  is  Phase  I  of  Small 
Business  Innovative  Research  (SBIR)  Topic  AF89-31  and  was 
performed  under  Contract  F19628-89-C-0080 . 

The  study  is  a  continuation  and  expansion  of  the  plan  described 
in  the  Airspace  Technology  Corporation  (Air  Tech)  Proposal  9173, 
Transition  Plan  for  Development  of  the  Automated  Tactical 
Aircraft  Launch  and  Recovery  System. 

Our  approach  for  developing  a  Proof  of  Concept  (POC)  model  will 
make  extensive  use  of  efforts  to  date  in  developing  the  SRV  and 
our  proposed  approach  for  the  NMR.  We  have  structured  the  plan 
to  include  efforts  which  could  be  performed  under  a  Phase  II 
SBIR.  We  propose  to  develop  a  laboratory  POC  model  to 
demonstrate  and  evaluate  certain  basic  system  capabilities.  We 
further  propose  the  possibility  of  using  an  SRV  for  limited  field 
testing.  We  would  use  the  system  presently  planned  as  the  CD-91 
option  to  the  Full  Scale  Development  Contract.  This  portion  of 
the  plan  is  described  in  Section  2.2. 

This  report  consists  of  five  main  sections.  Section  1, 
Introduction,  contains  a  brief  overview  of  Air  Tech's  ATALARS 
system  configuration  and  discussions  relative  to  the  major 
subsystems  elements,  including  current  status  of  various  systems 
and  technologies.  Section  2  describes  Air  Tech's  proposed  Proof 
of  Concept  (POC)  model  and  the  equipment  and  technologies  to  be 
included  in  a  laboratory  version  of  ATALARS  and  the  SRV  test  bed. 
Section  3  discusses  the  planned  evaluation  tasks  and  Section  4 
presents  the  planned  schedule  and  an  overview  of  the  task  efforts 
required  to  develop  the  POC  model.  Conclusions  are  presented  in 
Section  5. 

1 . 1  BACKGROUND 

Under  a  previous  SBIR  contract  (F19628-87-C-0195)  ,  Air  Tech 
performed  an  in-depth  analysis  and  evaluation  of  the  operational 
and  performance  requirements  which  could  be  expected  for  the  next 
generation  USAF  tactical  air  traffic  control  system. 

The  outcome  of  this  study  was  a  systems  concept  for  a  highly 
mobile,  tactical/survivable  ATC  system.  This  Advanced  Air 
Traffic  Control  System  (AATCS)  was  intended  to  be  one  approach 
toward  meeting  the  requirements  for  ATALARS. 
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The  AATCS  concept  and  the  ATALARS  system,  as  described  in  ESD-TR- 
86-259  and  other  subsequent  studies,  are  similar  in  basic 
function  and  operational  capabilities.  The  AATCS  system, 
conceived  under  Air  Tech's  previous  SBIR  contract,  was  defined  to 
a  level  whereby  specific  equipment  and  technologies  were 
identified  for  the  various  subsystems  and  functional  areas. 

Under  this  present  study  effort,  Air  Tech  proposed  to  develop  a 
transition  plan  for  a  hardware  and  software  suite  which  could 
perform  a  proof  of  concept  demonstration  for  ATALARS  using  our 
AATCS  configuration  as  the  strawman  system.  The  transition  plan 
would  describe  one  approach  for  continuing  the  development  of 
ATALARS,  initially  in  the  laboratory,  and  eventually  as  a 
demonstration  brassboard. 

1.2  PRELIMINARY  TASK  EFFORTS 

The  ATALARS  system  will  be  complex  in  terms  of  subsystems 
elements  and  technologies.  The  system  as  presently  envisioned 
does  not  break  any  new  ground  in  terms  of  component  or  basic 
system  technologies;  it  does,  however,  expand  on  existing 
technologies  and  on  hardware  and  equipment  in  advanced 
development . 

Preliminary  task  efforts  addressed  two  main  areas:  review  and 
update  of  the  status  of  the  various  systems  and  equipment  which 
made  up  the  strawman  system  configuration,  and  an  initial 
determination  of  the  critical  elements  of  ATALARS  which  would  be 
required  in  a  proof-of-concept  model. 

It  has  always  been  Air  Tech's  intention  to  build  ATALARS  around 
existing  technologies  and  equipment  to  the  degree  feasible.  This 
dictates  that  a  substantial  amount  of  effort  will  be  required  in 
the  area  of  requirements  allocation,  equipment  interface, 
interoperability,  and  control.  The  preliminary  tasks  have 
therefore  included  prioritizing  of  subsystem  definition  in  terms 
of  criticallity  in  producing  a  POC  model. 

In  the  course  of  this  study  effort,  Air  Tech  reviewed  our 
original  system  configuration  and  the  hardware  and  equipment 
originally  identified  for  the  requirement.  Key  elements  of  the 
system,  those  deemed  necessary  for  a  POC  model,  were  evaluated  as 
to  current  status  and  recent  developments.  Not  all  subsystem 
elements  incorporated  into  a  basic  ATALARS  would  be  required  for 
a  POC  equipment  suite. 
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1.3  BASELINE  SYSTEM  CONFIGURATION 

The  system  configuration  of  a  full-up  ATALARS  is  shown, 
functionally,  in  Figure  1.0  and  in  the  system  level  block  diagram 
provided  as  Figure  1.1.  This  configuration,  or  one  slightly 
reduced  in  performance/ operational  capability,  would  be  suitable 
for  a  field  deployable,  development  test  version.  A  scaled  down 
version,  suitable  for  a  POC  model,  is  described  in  Section  2.0. 

In  -rder  to  develop  a  program  or  transition  plan,  it  is  necessary 
that  the  system  be  broken  down  into  subsystem  or  technical 
elements.  This  allocates  specific  functional  requirements  into 
equipment  groups  which  can  be  designed,  developed,  and  tested 
independently.  The  individual  subsystem  elements  would  then  be 
incrementally  integrated  during  system  integration  and  test  to 
produce  the  complete  system. 

For  planning  purposes,  we  have  assumed  a  system  configuration  of 
six  major  subsystem  elements: 

Processing  and  Display,  the  main  system  processors, 
ancillary  and  peripheral  equipment,  the  controller 
displays  and  associated  workstation  hardware,  and  the 
system  software. 

Communications  Subsystem,  the  air-ground  and  land 
mobile  radios,  JTIDS  terminal,  landline  comm  (TRI-TAC) 
including  wireline  and  fiber  optics,  antennas  and  any 
associated  encryption  equipment. 

Communications  Network  Control,  the  processor/ formatter 
function  for  sequencing,  routing,  timing,  and  control 
of  uplinked  and  downlinked  ATALARS  voice  and  data. 

Aircraft  Positioning  Subsystem,  the  airborne  segment 
which  will  provide  the  interface  to  the  A/C  GPS/INS  and 
the  airborne  comm  equipment,  and  perform  the  processing 
and  control  of  uplinked/downlinked  voice  and  data. 

Cockpit  Data  Subsystem,  the  man/machine  interface  to 
the  pilot. 

The  Vehicle  Subsystem,  the  C-130  transportable  vehicle 
outfitted  with  operations/controller  workspace,  support 
facilities,  and  including  environmental  and  power 
equipment . 
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In  Air  Tech's  original  AATCS  configuration,  we  identified 
specific  equipment/technologies  applicable  to  the  ATALAP.S 
requirement.  A  number  of  specific  equipments  and  technologies 
are  still  prime  candidates  for  incorporation  into  ATALARS  and  in 
fact  are  still  evolving  and  improving.  Others  have  been 
overtaken  by  events  and  may  no  longer  be  a  prime  consideration. 

During  the  course  of  this  study  effort,  Air  Tech  reassessed 
certain  of  these  equipments/technologies  to  determine  the  present 
status  and  future  outlook. 

1.3.1  Processing  and  Display  Subsystem  (PDS) 

As  shown  in  Figure  1.3.1,  the  PDS  is  comprised  of  a  number 
of  subsystem  elements.  The  heart  of  the  subsystem  is  the 
System  Processing  Suite  (SPS) . 

In  Air  Tech's  original  system  configuration,  the  SPS  was 
planned  around  a  VMEbus  architecture  supporting  multiple  32 
bit  processors  and  intelligent  I/O  devices.  Recent 
developments  in  MULTIbus  II  and  FUTUREbus  technologies  have 
made  these  bus  structures  highly  suitable  candidates  for  the 
ATALARS  application. 

Adoption  by  the  Navy  of  FUTUREbus  as  a  standard  architecture 
makes  it  attractive  due  to  its  high  performance,  multi¬ 
processor  support  and  the  prospect  of  broad  vendor  support 
for  NDI  components. 

1.3. 1.1  Plasma  Displays 

The  AC  Gas  Plasma  Display  terminals  are  still  a  highly 
viable  technology  for  ATALARS  and  continue  to  be 
improved.  Recent  developments  include  large  screen  (14 
x  24  inch)  displays  for  NMR  and  an  improved  80386  based 
applications  processor  for  SRV.  Texas  Instruments  has 
developed  a  next  generation  Graphics  Processor,  the  TMS 
34020.  This  advanced  32  bit  processor,  expected  to  be 
available  in  a  MIL  qualified  version  in  approximately 
24  months,  could  be  applicable  to  SRV,  NMR,  and 
ATALARS . 

Much  effort  is  being  expended  ir.  the  areas  of  active 
matrix  Liquid  Crystal  Displays  (LCD)  and  Thin-Film 
Electroluminescent  (TFEL)  technologies.  Extending 
these  technologies  to  large  screen  displays  suitable 
for  military  applications  and  environments  is  a 
formidable  task.  Plasma  technologies  are  still 
dominant,  and  currently  available,  in  fully  militarized 
designs . 
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There  are  on-going  efforts  toward  development  of  high 
resolution  color  plasma  displays  under  a  NASA  Phase  II 
SBIR  and  a  HDTV  development  contract  from  DARPA. 

All  of  these  efforts  will  continue  to  improve  the  basic 
plasma  display  technology  and  all  are  applicable  to  the 
ATALARS  display  terminal. 

1.3.2  Communications  Subsystem 

ATALARS  will  require  communication  capability  covering  the 
air  traffic  control,  tactical  air  control,  and  command 
coordination  functions.  The  equipment  which  would  provide 
the  required  operating  capability  would  for  the  most  part  be 
inventory  items. 

The  key  element,  the  air-ground/ATC  function,  has  been 
planned  around  JTIDS,  HAVEQUICK,  and  SINCGARS  equipment. 
Air  Tech  believes  that  the  UHF ,  VHF  approach  using  HAVEQUICK 
and  SINCGARS  as  the  up/down  voice  and  data  link  warrants 
strong  consideration.  This  emphasis  is  driven  by  the 
planned  widespread  use  of  these  AJ  equipments  for  both 
airborne  and  ground  transceivers.  The  factors  which  will 
impact  the  suitability  of  this  approach,  and  which  would 
need  to  be  addressed  in  a  POC  model  are  discussed  in  Section 
2.0. 

Development  of  the  HAVEQUICK  equipments  is  on-going.  The 
program  has  proceeded  to  HAVEQUICK  II  and  IIA,  with  version 
II  being  an  improvement  to  the  original  equipment  concept. 
The  IIA  version  will  provide  additional  improvements 
including  a  faster  frequency  hopping  and  finer  frequency 
airborne  unit,  new  ground  radios  (GRC-XXX)  and  new  vehicular 
radios  (VRC-XXX) .  ESD  has  recently  awarded  contracts  to 
Rockwell-Collins  and  Motorola  to  continue  work  on  IIA 
versions . 

The  SINCGARS  ground  equipment,  being  manufactured  for  the 
U.S.  Army  by  ITT-Aerospace  Optical,  are  presently  in 
production.  ITT  is  also  developing  a  next  generation 
Integrated  Secure  r „,nmunications  (ICOM)  version  of  the 
radio.  A  second  source  award  for  SINCGARS  ground  radios  has 
also  been  made  to  General  Dynamics  Electronics/Tadiran 
Industries.  The  AF  contract  for  an  airborne  SINCGARS, 
HAVESYNC  (ARC-205) ,  with  Cincinnati  Electronics,  has  been 
terminated.  A  new  solicitation  is  expected  to  be  issued  by 
ESD  in  the  December  1989  time  frame.  Termination  of  the 
original  contract  will  certainly  delay  deployment  of 
interoperable  tactical  VHF  AJ  ground-air  equipment. 
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JTIDS  has  been  a  strong  candidate  for  the  ATALARS  data  link 
function.  The  basic  system  capabilities  include  a  number  of 
data  reporting  items  needed  for  ATC  functions.  This 
includes  the  Relative  Navigation  (RNAV)  and  Precise 
Participant  Location  and  Identification  (PPLI)  reporting 
features  which  would  provide  the  A/C  identification  and 
location  data  needed  by  the  ATALARS  processor.  JTIDS,  as 
originally  conceived,  was  not  intended  to  support  ATC 
operations.  Consequently,  some  problems  remain  to  be 
resolved  if  the  system  is  to  be  a  viable  part  of  an  ATALARS 
concept.  Certain  of  these  relate  to  message  set  content  and 
format  as  described  in  the  analysis/demonstration  report 
prepared  by  Analysis  and  Computer  Systems  (ACS)  under 
contract  F19628-87-C-0254 . 

An  additional  consideration  is  the  basic  JTIDS  network  cycle 
of  12  seconds.  There  will  be  situations,  such  as  close-in 
(60  miles  or  less)  ATC  operations  which  would  require 
position  update  rates  of  3  to  5  seconds.  The  possible 
degradation  of  the  ATALARS  position  data  rate  due  to  the 
JTIDS  network  structure  may  be  unacceptable  for  the  ATC 
function . 

A  very  fundamental  factor  in  planning  the  ATALARS 
communications  suite  is  the  planned  deployment  of  airborne 
JTIDS  terminals.  At  the  present  time,  a  limited  number  of 
platforms  are  scheduled  to  receive  JTIDS.  This  leaves  a 
large  number  of  fixed  wing  and  rotary  wing  aircraft  types 
which  still  must  be  accommodated  by  ATALARS. 

1.3.3  Communications  Network  Control 

A  critical  element  in  the  ATALARS  system  will  be  the  digital 
communications  link  between  the  ground  facility  and  the 
aircraft.  The  link  will  handle  aircraft  generated  position, 
identity  and  status  information  transmitted  to  ATALARS,  and 
advisories,  commands  and  information  requests  transmitted 
from  ATALARS  to  the  aircraft. 

The  link  must  support  a  data  rate  as  will  be  required  for 
the  real  time  target  tracking  and  decision  making  functions 
in  the  Processing  and  Display  System,  while  at  the  same  time 
maintaining  a  secure,  anti-jam  communications  channel. 

A  network  control  and  synchronization  function  will  be 
required  to  permit  an  orderly  and  non-interfering  exchange 
of  data.  This  function  is  resident  in  JTIDS,  which  provides 
the  necessary  levels  of  security,  network  synchronization, 
and  capacity. 
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The  use  of  the  HAVEQUICK  and  SINCGARS  radios  will  implement 
anti-jam  and  data  encryption  capabilities  at  data  rates  up 
to  16KB/ S ,  but  will  require  some  means  of  user-unique  time 
slot  assignment  and  synchronization,  i.e.  network  control. 

The  network  control  function  will  be  processor  based,  either 
as  a  stand-alone  device  or  as  part  of  the  System  Processor. 
Network  control  is  a  substantial  part  of  the  ATALARS  concept 
and  will  be  one  of  the  critical  elements  to  be  developed  for 
the  POC  model.  There  is  presently  no  identifiable  stand¬ 
alone  system  element  which  performs  this  function. 

1.3.4  Aircraft  Positioning  Subsystem 

ATALARS  will  be  unique  in  comparison  to  conventional  radar 
based  ATC  systems  through  the  concept  of  Aircraft  Derived 
Position  Data.  The  eventual  deployment  of  a  full 
constellation  of  GPS  satellites  will  provide  almost  complete 
worldwide  position  location  capabilities  for  all  GPS 
equipped  aircraft.  By  downloading  the  GPS  derived  data, 
alone  or  in  concert  with  data  from  the  aircraft's  on-board 
Inertial  Navigation  System  (INS) ,  via  a  suitable 
communications  scheme,  precise  aircraft  location  data  can  be 
provided  to  ATALARS. 

GPS  is  a  dynamic  technology  with  continuing  development  in 
both  ground  and  airborne  equipment.  Although  the  Aircraft 
Positioning  Subsystem  will  be  a  vital  element  in  a  field 
deployable  demonstration  ATALARS,  its  function  would  be 
simulated  in  a  POC  model. 

1.3.5  Cockpit  Data  Subsystem 

This  element  of  ATALARS  is  an  area  requiring  substantial 
study  and  analysis.  The  functions  required  to  enable  an 
efficient  flow  of  information  between  the  ground 
controller/system  and  the  pilot  will  involve  voice/data  and 
a  cockpit  display  capability. 

Voice  communications  will  be  retained  through  current  radio 
techniques,  either  in  the  clear  (conventional)  or  secure 
(anti-jam  or  encrypted) .  Presenting  digitally 
derived/transmitted  data  to  the  pilot  poses  some  complex 
problems  in  man/machine  interface,  human  factors,  and 
cockpit  work  load  considerations. 
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Initial  consideration,  only  at  a  very  elementary  level  so 
far,  have  included  heads-up-displays  (HUD)  and  synthesized 
voice  techniques.  HUD  systems  are  presently  used  for 
navigation/flight  control  and  tactical  weapons  systems. 
They  may  be  adaptable  to  support  the  ATALARS  ATC  function. 
Substantial  evaluation  remains  to  be  done  to  determine  the 
feasibility  of  implementing  ATALARS  with  these  existing 
systems . 

The  synthesized  voice  technologies  are  expanding  very 
rapidly,  both  in  basic  component  technology,  speech 
recognition  and  syntax  techniques,  and  speech  processing 
workstations.  Significant  efforts  in  adapting  voice 
recognition  techniques  to  ATC  simulation  systems  appears  to 
be  at  the  forefront  of  synthesized  voice  for  ATC 
applications . 

The  development  of  the  cockpit  subsystem  requirement  for 
ATALARS  will  most  probably  be  one  of  the  later  tasks  in  the 
system  development.  At  the  present  time,  AFSC-ASD  is 
continuing  to  work  on  the  Advanced  Cockpit  Program  (ACP)  . 
Some  of  the  features  to  be  investigated  for  the  ACP  include 
voice  recognition  and  voice  presentation.  At  the  point  in 
time  where  the  ATALARS  cockpit  man-machine  interface  and 
human  factors  are  better  defined,  it  should  be  presented  to 
the  ACP  project  group  for  consideration  in  the  development 
of  the  advanced  cockpit  operational  capabilities. 

A  type  of  cockpit  workstation  will  need  to  be  developed  for 
a  field  deployable  ATALARS  test  bed.  A  graphic  display 
simulation  would  be  implemented  for  the  POC  model. 

1.3.6  Vehicle  Subsystem 

This  element  of  ATALARS  is  the  lowest  priority  in  the  system 
evaluation.  The  basic  requirements:  C-130  transportability, 
high  mobility,  high  survivability,  fully  self  contained 
operation,  etc.,  can  be  met  using  today's  technologies  in 
vehicles  and  support  systems. 

Air  Tech  does  not  propose  to  do  any  development  work  on  the 
vehicle  subsystem  for  the  POC  phase  of  the  program. 
However,  transportability/mobility  guidelines  would  be 
followed  during  any  conceptual/developmental  efforts  to 
insure  that  the  final  system  configuration  would  meet  the 
deployment  requirements. 
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SECTION  2 

PROOF  OF  CONCEPT  MODEL 


The  concept  of  an  automated  passive  air  traffic  control  system 
raises  a  number  of  questions  and  apprehensions  regarding  the 
feasibility  and  outright  practicality  of  such  a  scheme. 

It  would  be  generally  agreed  that  a  system  such  as  ATALARS , 
configured  with  the  equipment  and  technologies  as  described 
herein  could  perform  the  functions  envisioned.  It  then  becomes 
necessary  to  take  the  system  concept  from  the  paper  stage  to  a 
point  in  the  system  development  cycle  where  key  technological 
questions  can  be  addressed.  In  Air  Tech's  ATALARS  concept,  we 
rely  heavily  on  hardware  and  equipment  in  inventory  or  in 
advanced  stages  of  development.  This  emphasis  on  existing 
equipment  reduces  the  overall  unit  level  development  effort,  but 
retains  the  necessity  for  a  very  strong  system  level  engineering 
effort . 

In  arriving  at  a  POC  system  configuration.  Air  Tech  evaluated 
those  elements  of  ATALARS  which  we  felt  were  critical  to  the 
basic  operating  premise  and  which  could  be  designed  and  evaluated 
in  a  Phase  II  effort.  We  identified  two  key  subsystem  elements 
which  must  be  evaluated  in  order  to  establish  the  feasibility  of 
our  ATALARS  approach.  These  two  subsystems,  (1)  Processing  and 
Display  and  (2)  Network  Control  are  both  considered  critical  and 
can  be  configured  as  a  POC  model  using  developmental  hardware  and 
software  and  simulation  devices. 

The  objective  of  the  POC  effort  would  be  the  development,  test, 
and  evaluation  of  the  critical  elements  of  ATALARS  as  a 
laboratory  test  bed.  Following  the  laboratory  testing,  we  would 
adapt  the  demonstration  system  configuration,  consisting  of  both 
ground-based  and  airborne  elements  to  further  refine  the  baseline 
system  concept.  We  would  propose  to  investigate  the  use  of  the 
CD-91  SRV  as  the  test  bed  for  this  limited  field  test. 

2 . 1  POC  MODEL  LABORATORY  CONFIGURATION 

As  shown  in  Figure  2.1,  the  POC  model  would  consist  of  three  main 
elements:  the  system  Processor  and  Display  suite,  the  Comm  Link 
Simulator,  and  up  to  N  Aircraft  Simulators.  The  software  and 
firmware  required  for  each  element  would  be  a  combination  of 
modified  and  newly  developed  code. 
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2.1.1  Processing  and  Display  Function 

The  technology  required  to  process  and  display  aircraft 
track  and  plot  data  is  highly  matured  and  widely  used  in  all 
major  ATC  systems.  The  full  capability  ATALARS  will  expand 
on  this  basic  capability  through  the  addition  of  collision 
avoidance  and  terrain  avoidance  algorithms,  also  widely  used 
in  ATC  systems,  and  flight  planning  and  routing  functions 
presently  not  common  to  terminal  control  systems. 

In  the  POC  system,  the  processor  would  perform  the  aircraft 
positioning  function  based  on  the  position  data  from  the  A/C 
simulators.  The  system  processor  will  interface  with  the 
network  processor,  peripheral  storage  devices,  and  the 
controller  displays.  Functionally,  it  will  perform  data  and 
input/output  management,  algorithm  processing  and  message 
generation.  The  man-machine  interface  and  a  significant 
amount  of  the  application  and  graphics  processing  will  be 
performed  in  the  controller  display  terminals.  The  displays 
proposed  for  the  POC  model  are  based  on  Air  Tech's  Model 
1024  Plasma  Display.  The  graphics  capabilities  incorporated 
in  these  displays  will  relieve  the  system  processor  of  much 
of  the  detailed  graphics  manipulations. 

2.1.2  Network  Control  Processor 

The  Network  Control  Processor  will  simulate  the  digital 
communications  link  which  would  transmit  aircraft  position, 
identity,  and  status  information  from  the  aircraft  to  the 
ground  based  elements  and  advisories,  commands  and 
information  requests  from  the  ground  station  to  the 
aircraft.  Network  control  and  synchronization  are  required 
in  order  to  permit  an  orderly  and  non-interfering  exchange 
of  data. 

In  the  POC  model,  the  processor  will  be  the  interface 
between  the  aircraft  Simulators  and  the  POC  System 
Processor.  It  will  be  configured  with  one  communications 
channel  for  each  simulator  and  will  perform  the  following 
functions: 

Link  control  and  conversion 

Uplink  and  downlink  time  synchronization 

Downlink  time  slot  assignments 

Message  data  buffering,  formatting,  and  code  conversion 

Local  time  reference  processing 
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Data  update  rates  will  be  addressed  independently  for  uplink 
and  downlink  operations.  Worst  case  will  be  the  downlink 
requirement,  since  each  aircraft  must  routinely  report  its 
position  on  a  regular  basis  to  permit  accurate  grcund-based 
tracking  and  real-time  display  to  be  performed.  The  uplink 
will  be  used  only  when  specific  advisories  or  requests  for 
information  must  be  transmitted  to  an  aircraft.  Current  ATC 
systems  require  a  three  to  five  second  update  rate  for 
terminal  area  traffic  (less  than  60  nmi  from  the  airfield) 
and  ten  to  fifteen  second  update  rates  for  long  range, 
enroute  aircraft  (60-300  nmi). 

In  the  POC  model,  we  would  propose  minimum  position 
reporting  intervals  of  3  seconds  for  targets  less  than  60 
nmi,  6  seconds  for  targets  between  60  and  120  nmi,  and  12 
seconds  for  targets  between  120  and  300  nmi. 

Since  the  type  of  data  and  transmission  rate  are  quite 
different  for  the  uplink  versus  the  downlink,  they  will  be 
considered  separately.  Additionally,  the  downlink  message 
rate  will  be  relatively  constant  for  a  given  number  of 
aircraft,  whereas  the  uplink  rate  will  vary  considerably 
depending  on  the  amount  of  advisory  and  control  information 
required  to  be  sent  to  specific  aircraft. 

The  primary  information  to  be  transmitted  on  the  downlink 
consists  of  aircraft  position  (latitude,  longitude,  and 
altitude) ,  unique  aircraft  identity  code,  and  status  codes 
and  service  request/acknowledge  codes.  Information  such  as 
speed  and  heading  could  be  derived  by  the  POC  system 
processor  similar  to  the  method  used  in  today's  radar  based 
systems . 

The  status  code  and  service  request/acknowledge  code  fields 
are  intended  to  provide  a  shorthand  method  of  transmitting 
common  status  information  such  as  low  fuel,  weapons  status, 
damage  status,  etc.,  and  service  request/acknowledgement 
such  as  alternate  routing,  weather,  airfield  status,  message 
confirmation,  etc.  Special  service-request  codes  could  even 
be  used  to  request  more  network  time  be  allocated  to  a 
particular  aircraft  to  allow  transmission  of  longer  text 
messages  on  a  non-routine  basis. 

A  basic  downlink  message  structure  could  contain  the 
following: 
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Information 

Diqits 

Bits 

Data  Capacity 

Latitude 

7  (BCD) 

28 

Deg. ,  Min. , 

Sec . 

Longitude 

7  (BCD) 

28 

Deg. ,  Min. , 

Sec . 

Altitude 

3  (BCD) 

12 

0-99,000  ft 

(100 ' s) 

Aircraft  ID 

4  (OCT) 

2 

4096  codes 

Net  ID 

2  (HEX) 

8 

256  nets 

Status 

2  (HEX) 

8 

256  codes 

Service  Req/Ackn 

2  (HEX) 

8 

256  codes 

Total  Info  Bits 

104 

Checksum/Error  Detection 

8 

Synchronization 

10 

Total  Bits/Message 

122 

The  uplink  messages  will  vary  depending  on  the  number  of 
aircraft,  frequency  of  update,  and  nature  of  the  message 
traffic.  A  basic  uplink  message  structure  could  contain  the 
following: 


Information 

Lenath 

Bits 

Data  Capacity 

Net  ID 

1  (byte) 

8 

256  nets 

Message  Type  Code 

1  (byte) 

8 

256  message  types 

Aircraft  ID 

4  (OCT) 

12 

4096  codes 

Length  Code 

1  (byte) 

8 

Up  to  256  data  bytes 

Data  Fields 

variable 

88 

Typical  10-byte 

message 

Total  Info  Bits 

116 

Checksum/Error  Detection 

8 

Synchronization 

10 

Total  Bits/Message 

134 

In  the  POC  model,  the  data  link  scheme  will  include  features 
deemed  critical  in  evaluating  the  overall  Air  Tech  ATALARS 
concept.  The  network  control  structure  must  be  synchronized 
such  that  Aircraft  Position  Reports  do  not  overlap  in  either 
the  airborne  or  ground  station  environment  and  the 
capability  should  be  provided  for  the  ground  station  to 
discretely  address  individual  aircraft  as  well  as  broadcast 
information  of  interest  to  all  aircraft.  In  addition,  the 
capability  should  be  provided  for  aircraft  to  randomly  enter 
the  system  without  benefit  of  pre-assigned  identity  codes  or 
time  slots. 


I 

I 
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Based  on  these  system  requirements,  Air  Tech  would  propose 
the  Multiple  Update  Rate,  Self-Synchronized  Data  Link  (MSDL) 
for  the  POC  model.  This  approach  establishes  a  full 
uplink/downlink  cycle  of  12  seconds,  subdivided  into  four 
sub-cycles  of  three  seconds  each,  i.e.,  SCA,  SCB,  SCC,  and 
SCD .  Each  three  second  sub-cycle  consists  of  300  slots  of 
10  milliseconds  each  for  a  total  of  1200  slots/cycle.  Each 
slot  includes  data,  synchronization,  checksum,  jitter,  and 
propagation  guard  bands. 

Network  synchronization  is  provided  by  a  special  message 
code  from  the  system  processor  which  transmits  the  ground 
station  coordinates,  net  identity,  as  well  as  a  cycle  start 
time  reference  mark. 

Each  aircraft  simulator  would  synchronize  an  internal  clock 
to  the  uplinked  cycle  start  mark  at  the  beginning  of  each 
cycle,  and  counts  through  all  1200  slots.  This  timer  is 
used  as  a  reference  by  the  aircraft  simulator  to  determine 
when  its  assigned  slot  time  starts. 

The  first  slot(s)  of  each  sub-cycle  would  be  allocated  to 
uplink  traffic,  with  the  remainder  for  downlink  traffic. 
The  first  four  downlink  slots  are  reserved  for  aircraft 
simulators  entering  the  net  which  would  randomly  transmit  a 
position  report  in  one  of  these  four  slots  during  one  of  the 
four  sub-cycles  (i.e.,  one  of  16  possible  slots  every  12 
seconds) .  The  systems  processor  will  log  the  aircraft  ident 
into  the  database  and  assign  it  a  discrete  time  slot  on  the 
next  uplink  message  slot  open.  subsequent  reports  from  the 
aircraft  simulator  would  be  transmitted  in  its  assigned 
slot . 

In  order  to  provide  multiple  position  update  rates,  aircraft 
simulators  would  be  assigned  sub-cycle  patterns,  as  well  as 
specific  slots.  Aircraft  at  close  ranges  would  be  assigned 
an  ABCD  pattern  resulting  in  a  report  every  three  seconds 
(once  per  sub-cycle) .  Intermediate  range  aircraft  would  be 
assigned  an  AC  or  BD  pattern  resulting  in  a  report  every  six 
seconds  (every  other  sub-cycle) .  Long  range  aircraft  would 
be  assigned  a  single  sub-cycle  pattern,  i.e.,  A,  B,  c,  or  D 
resulting  in  a  report  every  12  seconds  (once  per  cycle) . 

If  we  assume  a  distribution  of  uplink  messages  for  a  full 
capability  ATALARS  system  as  shown  below,  the  resulting 
average  uplink  rate  is  260  messages  per  minute,  or  about  52 
messages  per  12  second  cycle. 
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<40 

40-100 

100-300 


Message 

Interval 


No  -f 
Aircraft 


Total 
Msg  Rate 


30 

seconds 

100 

2 

minutes 

200 

5 

minutes 

300 

200  msgs/min 
100  msgs/min 
60  msgs/min 


Total 


600 


260  msgs/min 


This  will  require  that  the  first  13  slots  of  each  sub-cycle 
be  reserved  for  uplink  traffic.  Adding  three  slots  for 
synchronization  data  and  broadcast  messages,  the  first  16 
slots  of  the  300  slot  sub-cycle  would  be  reserved  for  uplink 
traffic.  This  leaves  284  downlink  slots  per  sub-cycle,  or 
1136  slots  per  12  second  full  cycle  (approximately  95 
slots/second) .  Various  distributions  of  short,  long,  and 
medium  range  aircraft  can  be  accommodated  by  dynamically 
assigning  either  a  3,  6,  or  12  second  reporting  interval  to 
aircraft  based  on  criteria  such  as  range,  mission 
criticality,  emergency  status,  etc.  A  typical  scenario  is 


shown  below. 

No.  of 

Reports/ 

Report 

Ranqe  (nmi) 

A/C 

cycle 

Time  Used 

Interval 

<40 

100 

4 

4.2  sec 

3  sec 

40-100 

-  200 

2 

4.2  sec 

6  sec 

100-300 

300 

1 

3.2  sec 

12  sec 

Total 

600 

11.6  sec 

(out  of  12  sec) 

The  ratio  of 

uplink  to 

downlink 

slots  in  a 

full -up  ATALARS 

could  be  increased  or  decreased  dynamically  as  well, 
depending  on  the  data  load  by  reassigning  discrete  aircraft 
reporting  slots  to  make  more  or  less  slots  available  to  the 
uplink  traffic.  If  additional  uplink  time  is  required 
without  compromising  traffic  capacity,  target  update  rates 
can  be  reduced,  or  a  second  uplink  channel  could  be  added  to 
permit  full  duplex  operation. 

The  POC  model  network  control  function  would  be  intended  to 
simulate  the  data  link  control,  synchronization,  and 
formatting  operations.  In  ATALARS,  this  would  be  performed 
using  the  ATALARS  system  processor,  JTIDS ,  HAVEQUICK,  and 
SINCGARS  radio  equipment  and  the  ATALARS  equipment  suite  in 
the  aircraft. 
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2.1.3  Display  Terminals 

The  displays  to  be  used  for  the  POC  model  will  be  14  x  24 
inch  AC  Gas  Plasmas.  The  addressable  resolution  will  be 
approximately  73  pixels  per  inch  (horizontal  and  vertical) 
providing  a  total  matrix  size  of  1024  x  1760  pixels.  The 
units  are  the  same  size  as  are  presently  used  in  the  NMR 
Demonstration  Operations  Center.  They  will  use  the  same 
high  speed  drive  electronics  as  are  used  in  Air  Tech's  14  x 
14"  SRV  display  extended  to  a  wider  matrix  size  in  the  x- 
direction.  Each  display  unit  will  consist  of  the  Plasma 
Display  head  and  associated  drive  electronics,  an 
Applications  Processor,  and  a  Graphics  Processor.  A 
separate  power  supply  is  located  external  to  the  display. 
The  proposed  combination  of  NMR  and  SRV  technology  was 
selected  to  reduce  non-recurring  costs  during  the 
development  of  the  POC  model. 

The  display  will  incorporate  operational  features  and 
performance  normally  associated  with  an  ATC  indicator,  i.e. 
selectable  ranges,  range  marks,  off-set,  centered  operation, 
etc.  Features  resident  in  the  basic  SRV  display  will  be 
retained  although  some  will  be  adapted  for  the  POC. 

Combining  the  features  of  the  SRV  display  with  the  larger 
NMR  type  display  will  provide  both  an  air  situation 
presentation  (PPI)  and  a  tabular/data  list  presentation,  as 
shown  in  Figure  2.1.3.  The  PPI  area,  approximately  13 
inches  in  diameter,  will  display  all  non-filtered  aircraft 
tracks  with  data  blocks  and  will  allow  the  operator  to 
select  geographic/navigational  symbols,  control  lists,  and 
maps.  The  tabular/ functional  area  of  approximately  10  x  14 
inches  can  be  used  to  display  flight  plan  data,  control 
lists,  filter  data,  free  text,  prompts,  etc. 

Man-machine  interface  to  the  system  will  be  via  soft 
switches  located  on  the  display  screen,  a  track  ball 
controlled  cursor,  a  touch  screen  overlay,  and  a  keyboard. 
Functions  most  frequently  used  are  operator  selected 
directly  from  the  area  where  the  current  status  is 
displayed.  For  functions  less  frequently  used,  a  pop-up 
menu  system  is  employed. 

A  touch  entry  panel  will  use  a  matrix  of  IR  emitters  and 
detectors  located  along  the  edge  of  the  display  panel. 
Resolution  is  0.125  inch  anywhere  on  the  display  surface. 
Touch  entry  would  be  used  primarily  for  operator  selection 
of  menu/action  soft  switches.  Other  functions  requiring  a 
closer  tolerance  data  entry  or  similar  action,  i.e.  target 
designation,  map  preparation,  etc.,  would  use  the  trackball 
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and  cursor  combination.  The  keyboard  would  be  used  for 
message  composition,  flight  plan  entry,  and  other  plain  text 
type  data. 

Geographic  data  required  for  normal  operation  and  for 
processor  based  routing  functions,  i.e.  maps,  minimum  safe 
altitude  warning  (MSAW)  profiles,  hazard  areas,  etc.,  are 
created  in  an  off-line  utility  accessed  via  a  menu  entry. 
To  create  a  map,  the  operator  would  input  points  on  the 
situation  display  using  the  trackball/cursor,  the  touch 
screen,  or  by  keyboard  entry  of  X-Y  coordinates.  Using  the 
menu,  the  operator  would  specify  the  type  of 
line/object/symbol  to  be  drawn  at  that  location.  Lines 
between  locations  are  drawn  after  entering  the  end  points, 
or  in  the  case  of  a  spline  curve  entering  points  along  the 
desired  curve. 

Selection  of  maps  is  done  by  placing  the  trackball  cursor 
over  the  desired  map  number  and  selecting.  Up  to  five  maps 
can  be  displayed  simultaneously  (overlaid).  Maps  are  stored 
in  non-volatile  EEPROM. 

Once  a  selection  has  been  made  from  the  map  preparation  menu 
for  creating  a -new  map  or  editing  an  existing  map,  that  sub¬ 
menu  remains  on-screen  until  the  operator  is  ready  to  save, 
abandon,  or  use  without  saving  that  map.  Up  to  32  pre¬ 
defined  map  symbols  will  be  provided  based  on  standard 
aviation  map  symbology.  Maps  can  be  rotated  and  translated 
relative  to  the  center  of  the  display.  The  map  drawing 
system  uses  a  simple  "point-and-shoot"  concept  for  placing 
lines  and  symbols. 

The  menu  system  is  used  for  less-used  functions  and  is 
accessed  by  selecting  the  menu  block,  or  via  the  menu  key. 
A  Menu  Window  pops  up  on  the  screen  and  is  only  visible  when 
called  up  and  disappears  after  the  selection  is  made.  All 
routine  quick-access  functions  do  not  display  the  menu. 
Menus  are  functionally  grouped,  providing  an  operator  with 
limited  training  a  logical  presentation  and  access  via  only 
two  levels.  An  exception  is  creation  and  editing  of  maps 
which  adds  a  third  level.  Menu  options  are  selected  by 
keypad  entry  of  item  number  or  by  selecting  a  menu  using  the 
trackball.  All  operations,  except  numeric  data  entry,  can 
be  done  with  the  trackball. 

Short  quick  action  entry  sequences  are  provided  for  the  most 
common  controller  operations.  Most  quick-access  operations 
are  performed  by  a  single  action  and  all  can  be  completed  in 
no  more  than  two  (exclusive  of  numeric  data  entry)  .  All 
functional  areas  are  accessed  and  modified,  as  applicable, 
by  using  the  trackball  to  place  the  cursor  over  the  area  and 
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pressing  the  trackball  select  key.  Selection  and/or  action 
functions  are  indicated  by  a  reverse  video  block.  For  data 
entry,  legal  entry  limits  are  displayed  in  the 
Freview/Response  area  and  the  entries  echoed  back. 
Operations  reguiring  specific  target  designation  use  the 
trackball  to  place  the  cursor  over  the  target  and  press  the 
trackball  select  button. 

To  select  the  display  range  and  range  marks,  the  controller 
uses  the  trackball,  range  and/or  range  mark  select  on-screen 
display  and  select  key.  Display  offset  is  done  by  selecting 
"set"  under  the  offset  on-screen  display,  positioning  the 
cursor  to  the  desired  radar  origin  location,  and  pressing 
locate.  To  return  to  center,  select  center  on  the  screen. 
Return  to  the  previously  "set"  origin  is  accomplished  by 
selecting  "set"-  and  then  pressing  locate  without  moving  the 
trackball  cursor. 

A  readout  of  the  cursor  range  and  azimuth  relative  to  the 
display  center  is  displayed  continuously  in  the  upper-right 
section  of  the  screen.  Relative  range  and  bearing  between 
any  two  points  can  be  measured  by  relocating  the  cursor 
origin  reference  to  a  point  of  interest  and  pressing  the 
"locate"  button.  All  subsequent  movement  of  the  cursor  will 
show  range  and  bearing  relative  to  the  new  reference  point. 

The  tabular  display  area  will  be  used  for  procedural  data, 
i.e.,  simulation  of  operational  information  -  weather  and 
NOTAMS  and  dynamic  ATC  control  data  -  arrival/depature 
lists,  flight  strips,  and  processor/control  information. 

2.1.4  Aircraft  Simulator 

In  the  POC  model,  we  will  need  to  simulate  the  functions 
which  will  eventually  be  performed  by  an  ATALARS  airborne 
equipment  suite.  The  very  basic  capabilities  would  be  the 
generation/control/transmission  of  aircraft  position  data 
and  a  simulated  pilot  interface/display  function. 

Air  Tech  proposes  to  use  PC  type  terminals  for  each 
simulator  station.  The  units  would  be  programmed  to  provide 
simulated  flight  routings  -  start  point,  routings  via 
waypoints,  to  an  end  point.  Enroute  altitudes,  ground 
speed,  and  A/C  ident  would  be  established  in  the  A/C  flight 
plan.  The  simulation  program  will  be  similar  to  the 
routines  written  by  Air  Tech  to  exercise  the  SRV  display 
terminals,  but  with  increased  capabilities  as  required  for 
the  POC  model.  Simulations  would  include  the  capability  to 
emulate  specific  A/C  performance  parameters,  i.e.,  speed, 
altitude,  turn  rate,  etc.  A  pseudopilot  at  each  simulator 
would  input  to  the  terminal  all  flight  specific  data  and 
select  A/C  performance  data  from  a  menu. 
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The  simulator  would  output  an  A/C  data  message  -  ident, 
latitude,  longitude,  altitude,  plus  any  special  mission  data 
-  via  the  network  control  processor,  synchronized  with  the 
up/down  data  link  scheme. 

The  PC  display  terminal  and  keyboard  would  be  the 
pseudopilot's  interface  to  the  POC  system.  The  display 
would  show  three  types  of  tabular  data  -  the  A/C  position 
message  as  downlinked,  ATC  advisory  data/messages,  uplinked, 
and  a  preview/message  composition  area.  Control  and  data 
entry  into  the  simulator  would  be  via  the  keyboard. 

2.2  POC  MODEL  FIELD  TEST  CONFIGURATION 

The  TRV/SRV  full  scale  development  program  is  approximately  three 
months  into  its  scheduled  24  month  duration.  Although  it  is  too 
early  in  the  program  to  determine  the  feasibility  of  the  idea,  we 
would  propose  to  perform  a  limited  field  test  of  the  ATALARS  POC 
laboratory  model  using  an  SRV  as  the  basic  ATC  facility.  This 
approach  would  allow  limited  testing  of  the  basic  ATALARS  system 
concept  without  a  major  expenditure  of  funds  and  within  a 
reasonable  time  frame.  The  ATALARS/SRV  approach,  described 
below,  will  require  coordination  with  the  various  participants  in 
the  TRV/SRV  program,  i.e.,  AFCC  and  ESD/TVCN/PKTP ,  in  order  to 
utilize  the  SRV  for  the  ATALARS  application.  At  the  completion 
of  the  ATALARS  testing,  the  SRV  would  be  brought  back  to  its 
original  configuration. 

2.2.1  CD-91  TRV/SRV  System 

The  present  TRV/SRV  Full  Scale  Development  (FSD)  contract 
includes  an  option  for  one  each  TRV  and  SRV  to  support  the 
Constant  Demo-91  exercises  in  Europe.  The  intent  is  to 
develop  the  CD-91  units  in  parallel  with  the  FSD  units. 
They  will  be  functionally  the  same,  but  without  the  full 
testing  required  under  FSD. 

The  CD-91  schedule  calls  for  system  delivery  early  in  1991, 
with  the  European  exercises  conducted  in  the  May-June  time 
frame  of  that  year.  The  CD-91  units  would  be  expected  to  be 
returned  to  Air  Tech  in  the  August-September  time  frame  for 
refurbishment  and  updating.  At  that  point,  the  ATALARS  POC 
development  effort  would  be  expected  to  be  well  into  the 
laboratory  system  development  and  evaluation  phase. 

We  would  propose  to  adapt  the  SRV  to  incorporate  the  ATALARS 
Processing  and  Network  Control  functions,  using  the  SRV 
Plasma  Displays  and  on-board  HAVEQUICK  radios.  We  would 
retain  the  SSR  capability  which  would  provide  a  cross-check 
against  the  ATALARS  detection  and  tracking  functions. 
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We  would  need  to  develop  a  Processor-Formatting  device  to  be 
installed  in  a  GFE  aircraft  which  would  interface  with  the 
aircraft  GPS/INS  system  and  airborne  HAVEQUICK  radio  to 
provide  very  rudimentary  A/C  position  data.  The  airborne 
package  would  be  a  compact  unit  designed  to  readily 
interface  with  the  aircraft  equipment  without  modifications 
or  changes  to  the  aircraft. 

2.2.2  SRV/ATALARS  System  Configuration 

The  configuration  of  the  POC  model  interfaced  with  the  SRV 
is  shown  in  Figure  2.2.2.  The  network  control  processor 
hardware  could  be  readily  installed  in  the  SRV  shelter  and 
interfaced  to  one  of  the  AN/VRC-83  radios.  The  system 
processor  interface  to  the  SRV  14"  x  14"  plasma  displays 
would  be  through  one  of  the  spare  RS-232  I/O  parts  which  are 
available . 

The  interface  to  the  SRV  system  elements  are  straightforward 
and  can  be  done  without  any  major  changes  or  modifications 
to  the  SRV. 

The  objective  of  the  limited  field  test  would  be  to  exercise 
the  air-ground  comm  scheme  and  evaluate  the  effectiveness  of 
both  the  comm  and  processing  techniques. 
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SECTION  3 
POC  EVALUATION 


The  objective  of  this  SBIR  effort  is  to  develop  a  preliminary 
implementation  approach,  utilizing  planned  or  existing  systems, 
for  an  ATALARS  POC  model. 

We  based  our  fundamental  ATALARS  system  concept  on  the  system  we 
had  derived  in  our  previous  SBIR  study.  We  then  evaluated  that: 
system  concept  to  determine  what  elements  could  be  initially 
implemented  in  a  POC  model,  taking  into  consideration  on-going 
developments  in  technology  and  the  constraints  imposed  for  an 
SBIR  Phase  Two  contract. 

The  system  configuration  for  the  POC  model,  as  described  in  2.0, 
is  intended  to  form  the  basis  for  evaluating  what  are  considered 
major  technical  elements  in  the  basic  ATALARS  concept,  i.e., 
Processing  and  Display  and  Network  Control. 

The  processor  and  its  associated  software  and  the  plasma  display 
terminals  and  their  firmware  would  address  two  basic  functions. 
The  first  would  be  the  generation  and  execution  of  algorithms  to 
process  simulator  generated  aircraft  position  data  and  to  display 
and  update  aircraft  positions  based  on  that  data  and  on 
information  resident  in  the  static  and  dynamic  data  base.  The 
system  processing  capabilities  would  be  evaluated  to  determine 
the  feasibility  and  effectiveness  of  the  processing  routines  and 
the  ability  of  the  software  to  determine  rudimentary  flight 
routings  and  to  select  recommended  control  procedures  for 
subsequent  transmittal  to  the  aircraft. 

The  second  Processing  and  Display  system  function  to  be  evaluated 
would  be  the  Man-Machine  Interface  (MMI)  to  the  system.  The 
basic  SRV  MMI  features,  and  certain  of  Air  Tech's  proposed  NMR 
MMI  features  would  be  evaluated  along  with  the  preliminary 
ATALARS  features  which  would  be  added. 

The  evaluation  of  the  Network  Control  function  will  address  the 
suitability  of  the  proposed  uplink/downlink  scheme  for  the 
ATALARS  data  exchange.  Two  basic  considerations  will  need  to  be 
addressed.  First  will  be  the  networking  and  data  formatting 
scheme,  we  will  need  to  assess  the  uplink  and  downlink  message 
structure  and  update  times  and  the  overall  networking  control  and 
sequencing  methodology. 
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Although  the  plan  is  to  utilize  a  limited  number  of  Aircraft 
Simulators,  we  will  need  to  simulate  a  larger  number  of  aircraft 
messages  in  order  to  evaluate  a  higher  rate  of  uplink  and 
downlink  message  traffic.  We  would  specifically  address  any 
potential  for  problems  relative  to  time  slot  allocations,  initial 
entry  into  the  net,  propagation/ j itter  problems,  and  optimum 
message  lengths. 

The  analysis  and  measurements  to  be  performed  on  the  suitability 
of  the  HAVEQUICK  and  SINCGARS  radios  to  handle  data  linked 
message  *';affic  will  address  two  areas:  capability  to  support  the 
data  rates  and  the  impact  of  data  transmission  and  reception  cn 
voice  transmission/reception. 

The  outcome  of  the  POC  development  and  test  effort  will  be  a 
determination  as  to  the  suitability  of  Air  Tech's  basic  ATALARS 
concept  as  a  next  generation  ATC  system.  We  will  have  addressed, 
albeit  to  a  limited  degree,  two  of  the  major  areas  which  we  feel 
are  critical  to  the  premise  of  aircraft  derived  position  data  and 
the  processing  and  control  functions. 

If  it  becomes  possible  to  use  the  SRV  as  a  test  bed  in 
conjunction  with  the  airborne  message  processor-formatter  in  a 
Government  aircraft,  we  will  be  able  to  exercise  the  data  link 
function  and  the  display  and  tracking  function  in  an  operational 
environment . 

The  report  which  will  be  generated  at  the  conclusion  of  the 
effort  will  include  a  detailed  description  of  the  system, 
including  hardware  and  software  elements.  The  report  will 
include  copies  of  the  test  procedures  and  results  and  evaluation 
and  analysis  of  those  results.  The  report  would  cover  both  the 
laboratory  efforts  and  the  SRV/ATALARS  test  results. 
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SECTION  4 
PROGRAM  SCHEDULE 


The  ATALARS  Transition  Plan  needs  to  address  two  phases  in  the 
overall  system  evaluation:  the  POC  model  development  and  the 
longer  range  Prototype,  Engineering  Development,  and  Production 
phases. 

In  this  section,  we  will  address  the  overall  system  engineering 
approach,  incorporating  the  POC  phase  and  based  on  an  estimated 
sequence  of  events  and  time  periods  (Figure  4.0).  We  will  also 
provide  a  PERT  chart  for  the  POC  effort. 

4.1  SYSTEM  ENGINEERING 

The  System  Engineering  functions  shown  in  Figure  4.0  are  intended 
to  show  the  types  of  efforts  to  be  required  in  evolving  the 
ATALARS  system.  The  sequence  of  events,  albeit  quite  simplified, 
will  serve  to  identify  and  define  the  functional  characteristics 
of  the  ATALARS  system  hardware,  software,  and  support  structure 
through  the  process  of  analysis  and  design.  The  process  would 
ensure  an  effective  analysis  of  the  mission  requirements  which 
would  in  turn  become  the  system  design  requirements. 

The  Feasibility  and  Concept  Formulation  stage  have  been  at  least 
partially  performed  through  efforts  to  date.  To  our  knowledge, 
the  preliminary  Life  Cycle  Cost  assessment  has  not  been 
performed.  The  next  phase,  the  Concept  Exploration,  is  what  we 
are  addressing  in  this  effort.  The  outcome  of  this  SBIR  can 
possibly  go  a  long  way  toward  setting  the  ground  rules  and 
developing  the  system  specifications  for  the  Engineering 
Development  Phase. 

Refinements  which  come  out  of  Engineering  Development  as 
operational,  performance,  or  technical  issues  are  analyzed  and 
evaluated  in  the  Demonstration  Validation  Phase  and  would  be 
incorporated  in  the  revisions  to  the  system  specifications.  At 
this  stage,  the  System  Engineering  Management  Plan,  including  the 
supporting,  control,  and  program  management  functions,  are 
evolved  into  a  Full  Scale  Development  system  solicitation 
package . 
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The  F5D  phase  will  produce  systems  which  incorporate  all  of  the 
System  Engineering  disciplines  in  addition  to  hardware,  software, 
firmware,  and  facilities  requirements  and  specifications. 
Successful  completion  of  DT&E  and  IOT&E  during  the  FSD  phase  will 
establish  the  confidence  levels  in  performance,  operability,  and 
fulfillment  of  mission  requirements,  all  under  deployed 
conditions.  This  in  turn  would  normally  lead  to  a  decision  to 
proceed  to  a  production  run  of  ATALARS  systems. 

In  Figure  4.0,  we  included  time  references/spans  for  the  various 
phases.  These  are  intended  to  be  representative  only  and  should 
not  be  considered  as  firm  milestones  in  the  program. 

4 . 2  POC  DEVELOPMENT  TASKS 

Three  task  areas  are  planned  for  the  POC  development  as  shown  in 
Figure  4.2.  The  Processing  and  Display  subsystem  will  be  based 
on  the  SRV  display  technology.  We  will  initially  translate  the 
operational  and  performance  features  described  in  this  report 
into  a  series  of  tasks  associated  with  hardware,  software,  and 
firmware  elements.  This  will  include  modification  to  the  SRV 
display  Applications  and  Graphics  processor  designs  to  operate 
with  the  14"  x  24"  plasma  display  panel,  adaptation  of  existing 
software  and  firmware,  and  generation  of  new  software. 

The  POC  processor  development  will  include  both  hardware  and 
software.  The  preliminary  plan  is  to  use  board  level  assemblies 
to  configure  the  processor. 

The  Network  Control  Processor  function  will  be  developed  as  an 
additional  processing  element  in  a  multiple  processor  hardware 
configuration  of  single  board  computers.  Two  main  tasks  are 
involved,  an  in-depth  analysis  of  the  proposed  communication 
equipments  (HAVEQUICK,  SINCGARS,  and  JTIDS)  and  development  of 
the  link  simulation  technique  and  associated  hardware  and 
software . 

The  equipment  analysis  will  address  the  capabilities  of  the 
various  transmitting  and  receiving  equipment  to  handle  the 
proposed  data  link  message  formats  and  the  impact  of  data 
transmission  on  the  simultaneous  use  of  the  radios  for  voice 
transmissions . 

Refinement  of  the  data  link  scheme  and  development  of  the  link 
simulation  hardware  and  software  will  address  the  basic  data  link 
technique  in  terms  of  message  content  and  format,  and  data  rate. 
We  will  also  address  the  applicable  hardware  technology  and 
associated  software  required  for  implementation.  The  initial 
plan  to  use  a  board  level  processor  will  reduce  the  hardware 
design  effort,  the  major  tasks  being  selection  of  applicable  off- 
the-shelf  hardware.  The  software  development  will  include 
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requirements  analysis,  coding  and  module  testing  to  the  point 
where  hardware  integration  occurs.  At  this  stage,  the  Network 
Control  function  would  be  tested  at  the  subsystem  level. 

Aircraft  simulators  are  planned  to  be  PC's  with  monitors  and 
keyboards.  The  software  requirements  will  establish  the 
functional  performance  in  terms  of  aircraft  flight  parameters  and 
man-machine  interface.  The  aircraft  position  data  and  flight 
routings  will  be  based  to  a  degree  on  routines  developed  for  the 
simulator  used  to  demonstrate  the  SRV  display.  For  the  POC 
application,  these  routines  will  be  dynamic  and  can  be  modified 
by  keyboard  entry  to  change  flight  parameters. 

The  man-machine  interface  will  be  via  a  tabular  data  display  and 
the  keyboard.  Upon  completion  of  subsystem  development  efforts, 
the  three  subsystems  will  be  fully  integrated  and  tested  as  a  POC 
model . 
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SECTION  5 
CONCLUSIONS 


The  requirement  for  a  next  generation  tactical  Air  Traffic 
Control  system  remains  as  a  valid  element  in  the  evolution  of 
worldwide  ATC  facilities.  On-going  efforts,  including  deploying 
the  MPN-14K,  developing  and  producing  the  TRV/SRV,  NMR,  and  FAA 
Advanced  Automation  System,  and  continuing  projects  to  upgrade 
and  modernize  existing  fixed  and  mobile  ATC  assets  have  as  a 
common  denominator  reliance  on  active  sensors  and  radar  emitters. 

Vie  will  shortly  enter  a  new  era  in  the  technologies  and 
operational  concepts  to  be  used  for  the  ATC  functions.  We  will 
eventually  see  almost  total  reliance  on  satellite  based  systems  - 
surveillance,  communications,  and  navigation  -  for  civil  and 
military  ATC.  Although  a  high  level  of  interoperability  will  be 
required  between  the  military  and  civil  systems,  a  continuing 
need  will  exist  for  a  military  system  which  can  operate 
independently  from  a  fully  satellite  based  surveillance  and 
control  system. 

The  basic  ATALARS  system  premise:  aircraft  derived  position  data, 
conventional  air-ground  up/down  data  link,  and  the  extensive  use 
of  processor-based  control/decision  elements  is  suitable  for  a 
purely  military  application.  It  could  eventually  be  configured 
as  an  ATC  system  which  will  operate  in  conjunction  with,  or  as  an 
alternate  to,  a  communications  satellite  as  the  data  link 
element . 

The  ATALARS  concept  is  one  means  of  providing  this  military- 
oriented  capability  and  is  a  first  step  in  the  use  of  satellite 
technology  -  GPS  -  for  ATC.  In  evolving  the  proof-of-concept 
model  configuration,  we  have  proposed  a  bridge  between  today's 
technology  and  our  perception  of  tomorrow's  military  operational 
requirements.  Within  the  constraints  of  an  SBIR  program,  we  have 
proposed  an  elementary  system  configuration  which  employs  SRV  and 
NMR  subsystem  technologies  to  demonstrate  critical  operating 
features  in  the  ATALARS  system  concept. 

Our  approach  is  intended  to  further  the  ATALARS  concept  and  is 
aimed  at  the  eventual  development  of  a  system  with  the 
capabilities  to  monitor  and  control  a  high  number  of  aircraft 
movements,  over  a  large  area,  under  peacetime  and  wartime 
operating  conditions,  anywhere  in  the  world. 
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